1. Field of the Invention
This invention relates to accessing data in a database from a web browser on the internet, and more specifically to a system, method, and program for interfacing web applications, which parse requests from the web browser, to a database management system.
2. Description of the Related Art
The ubiquity of the internet's world wide web has opened up new dimensions for commerce. Previously, electronic transactions were exclusively used by highly sophisticated business enterprises, such as banks, that could afford to (or could not afford not to) use computer controlled communications. Today, the internet can provide the efficiency of electronic transactions among business enterprises and customers at significantly low costs for the medium to small business. The world wide web, and its successors, are viewed as a well accepted standard communications protocol.
The increasing role that the internet is playing in commercial transactions is spawning the development of new database management system applications that are at the heart of these commercial transactions. Data base management systems, the mainstay of book-keeping, for service sensitive transactions and the world wide web are today's foundations for service sensitive electronic transactions.
The requirements of web applications that access a database are different from that of conventional database applications. The "all-or-nothing" semantics of the flat transaction model supported by most commercial database systems is generally adequate for conventional applications. Web applications typically require selective recoverability, i.e., flexibility in deciding what should be committed to the database. Also, web applications can have transaction structures that require a combination of more than one transaction model, e.g. supporting flat, nested and chained transaction models in a transaction structure. A complex transaction structure is defined herein as any transaction structure or combination of transaction structures that includes at least one non-flat transaction structure. For example, see Jim Gray, Andreas Reuter, "Transaction Processing: Concepts and Techniques," Morgan Kaufman Publishers, Inc., 1993, chapters 1 and 4.
As an example, consider a typical travel agency application that allows customers to plan a vacation trip. The customer is given access to the required databases of airline companies, home care and car rental agencies. The whole trip planning activity can be considered a top-level transaction and nested within it are lower-level transactions in the form of accesses to individual agency databases.
Assume that a customer wants to plan an itinerary from city A to city F going through cities B, C, D and E. Also, assume that the customer plans to be away from home whether or not the customer succeeds in finding the right reservations for the itinerary, and wants to request a home care agency to take care of the customer's home during the vacation period. The choice of cities in the itinerary depends on availability of airline and car rental reservations.
FIG. 1 shows a typical transaction structure. At any point (before making the final payment), the customer may chose to cancel the vacation, i.e., rollback all airline and car reservations requested on behalf of the customer. Alternatively, if a car reservation is not available at a city, the customer may chose to drop the city from the itinerary and make an alternate airline reservation.
For example, in FIG. 1, if the customer does not find a car rental reservation at city C, 111, the customer may drop the city from the itinerary and look for an alternate route. The subtransaction 112 in the home care agency database will not be rolled back since the customer intends to be away from home anyway. However, the ongoing subtransaction 113 in the airline database should remain active together with the subtransaction 114 in the car rental database to finalize the itinerary.
To summarize, the overall structure is that of a chained transaction with the subtransaction in the home care agency database forming one part of the chain. The second part of the chain has a nested structure consisting of subtransactions in the airline and car rental agency databases. Within the nested structure, the customer should be given the flexibility of canceling reservations and making new ones i.e., selective recoverability.
Conventional database applications will have application specific logic that is predetermined depending upon the transaction structure of the application. However, with web interfaces, the transaction structure of an application may not be pre-determined. It may be determined by the user by way of the sequence in which actions are requested at the database; and, more specifically, by the order in which hyper-links are selected for navigation.
To support applications similar to the one described above, state information about the application must be maintained. In the example above, state information includes details about the reservations made and what the customer owes to individual agencies. Hence these applications are "state-dependent".
Web applications accessing a database have typically been supported using the Common Gateway Interface (CGI) standard. The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web Servers. A Web daemon will execute the CGI program to transmit information to the database engine and to receive the results back for display to the client. Briefly, when a user uses the web browser to access a file in a directory called the CGI-BIN, the file is executed and the results are returned to the web browser (instead of the file itself being returned to the browser). The CGI specifies interaction between a program and a web browser, not the interaction between the program and a database. For example, see "Common Gateway Interface," and "The Common Gateway Interface" CGI-Common Gateway Interface, cgi@ncsa.uiuc.edu.
Every request to the CGI-BIN file causes the file to be executed and the results returned to the browser. Hence, the CGI-BIN file cannot maintain state information between successive invocations. However, the state information can be stored in the hidden fields of the Uniform Resource Locator (URL) that points to the file so that it can be used during successive invocations. This solution is expensive since the amount of state information in the context of applications accessing a database can be large. In such applications, the CGI-BIN file contains SQL commands that connect to the database, execute requests, disconnect from the database and pass the results to the browser.
A typical application is to browse a shopping catalog through the web, where the catalog itself is assumed to be stored in a database. As a customer browses through the catalog, the customer can select items to order. Among the selected items, the customer may further chose to place orders on some items and not to place orders on the rest. Thus the application and its interface to the database should allow the customer to selectively recover some of the selections (i.e., not place orders on some selections) the customer made prior to making the payment. To support recoverability at a later stage, information about all selections should be maintained. Hence state information should be maintained across invocations of the CGI-BIN file.
Application Ser. No. 08/491,742, filed Jun. 19, 1995, entitled "ACCESSING A RELATIONAL DATABASE OVER THE INTERNET USING MACRO LANGUAGE FILES", is an example of an interface for web applications accessing a database. The CGI-BIN program in the interface parses SQL commands in macro language files, connects to the database, executes the commands and returns results to the web browser. Since the program is alive only for the duration of a request, state information cannot be stored in the program.
Since commercial database systems support a flat transaction structure and since the program cannot maintain state information across invocations, applications that have different transaction requirements cannot be supported. An interface that can support all of such applications is previously unknown.